Methods for managing an interactive streaming image system

ABSTRACT

Methods for managing an interactive streaming image system are disclosed. More particularly, hardware and/or software for generating, encoding, and transmitting image frames to an interactive client are disclosed. One embodiment provides a method for streaming images from a server to a client. Embodiments may include receiving from the client via a network client information and generating a new image frame based on the received client information. Embodiments may also include comparing the new image frame and a previous image frame and setting a new compression level based on the comparison between the new image frame and the previous image frame. Embodiments may also include encoding the new image frame based on the new compression level and transmitting the encoded new image frame and an indication of the new compression level to the client via the network.

FIELD OF INVENTION

The present invention is in the field of streaming image systems. Moreparticularly, the present invention relates to methods for managing aninteractive streaming image system to stream images to client computersystems.

BACKGROUND

The ability to stream images or other content from a server to multipleclients is a quickly-growing need. Multi-media applications that utilizestreaming images continue to increase in popularity and include videogames, navigation software, streaming movies or video, and the like.These applications, however, often are network-resource intensive andresult in bandwidth bottlenecks and network slowdowns when contentproviders use them to distribute content, particularly to large numbersof users. As the popularity of streaming image applications continues toincrease, the network performance problems associated with them will beexacerbated.

To reduce the impact of streaming image content on a network, contentproviders often compress their images before transmission. The clientsystem must then decompress the image upon receipt before displaying theimage to a user. Depending on the level of compression, network trafficcan be significantly decreased by utilizing compression. One compressionscheme for video images is motion-JPEG which extends the JointPhotographic Experts Group (JPEG) digital image compression standard tovideos by encrypting each frame in the JPEG format. The JPEG groupcreated the ISO/IEC International Standard 10918-1 ITU-T RecommendationT-81 (hereinafter ‘JPEG’) to create a decoding/encoding standard. JPEGand Motion-JPEG are lossy compression standards and thus information islost during the compression process. Motion-JPEG provides good per-framecompression levels but some of its compression steps, such as Huffmancoding, are not always necessary and can slow performance.

The Moving Pictures Experts Group (MPEG) created another family ofcompression standards that include MPEG-1, MPEG-2, and MPEG-4 (ISO/IECInternational Standards 11172, 13818, and 14496, respectively). The MPEGworking group designed the MPEG standards to work for multi-mediastreaming and utilize block-based motion compensated prediction (MCP) toassist in compression. For many applications, MPEG improves upon theperformance of motion-JPEG. For interactive streaming imageapplications, however, MPEG is not optimal. MPEG requires a server togenerate multi-frame movies to achieve good compression levels, makingit less useful for interactive applications that have frame-by-frameinteractions. Instead, MPEG is designed and optimized for streamingpredictable content, such as movies or other videos, to client or otheruser devices.

Interactive streaming image systems provide significant challenges tocontent providers desiring to distribute content from a server tomultiple clients. Interactive streaming image systems typically receiveuser input for each frame so that each image frame is customized basedon the latest user information. A map-based application, for example,might provide an image frame based on user position and heading so thatthe application could create an image showing the user what they wouldsee at that position and heading. In another example, an applicationthat displays a virtual view of what is behind an automobile may baseits image on the current position, direction, and speed of theautomobile. Because each frame must be recalculated based on newinformation, MPEG does not provide an efficient method as it does notachieve its best compression rates when working with single frames.Similarly, motion-JPEG does not provide any advantage when used withinteractive streaming image systems as it applies a compression methodthat may be too resource-intensive for each image frame.

There is, therefore, a need for an effective mechanism for managing aninteractive streaming image system. There is an even greater need forsuch a mechanism when a content provider desires to provide interactiveimage content to multiple client systems.

SUMMARY

The problems identified above are in large part addressed by methods formanaging an interactive streaming image system. One embodiment providesa method for streaming images from a server to a client. Embodiments maygenerally include receiving from the client via a network clientinformation and generating a new image frame based on the receivedclient information. Embodiments may also include comparing the new imageframe and a previous image frame and setting a new compression levelbased on the comparison between the new image frame and the previousimage frame. Embodiments may also include encoding the new image framebased on the new compression level and transmitting the encoded newimage frame and an indication of the new compression level to the clientvia the network. A further embodiment may include determining a contentchange between the new image frame and the previous image frame,performing a smoothing heuristic on the new image frame to decreasequality, and setting the new compression level based on the smoothingheuristic. A further embodiment may include determining no contentchange between the new image frame and the previous image frame,performing a smoothing heuristic on the new image frame to increasequality, and setting the new compression level based on the smoothingheuristic.

BRIEF DESCRIPTION OF THE DRAWINGS

Other objects and advantages of the invention will become apparent uponreading the following detailed description and upon reference to theaccompanying drawings in which, like references may indicate similarelements:

FIG. 1 depicts an environment for a system for streaming images from aserver to a plurality of clients according to one embodiment;

FIG. 2 depicts the structure of a client of the streaming image systemof FIG. 1 according to one embodiment;

FIG. 3 depicts an example of a flow chart for generating, encoding, andtransmitting a new image frame according to one embodiment;

FIG. 4 depicts an example of a flow chart for receiving user input andreceiving and displaying an image frame to a user according to oneembodiment; and

FIG. 5 depicts an example of a flow chart for encoding and decoding animage frame according to one embodiment.

DETAILED DESCRIPTION OF EMBODIMENTS

The following is a detailed description of example embodiments of theinvention depicted in the accompanying drawings. The example embodimentsare in such detail as to clearly communicate the invention. However, theamount of detail offered is not intended to limit the anticipatedvariations of embodiments; but, on the contrary, the intention is tocover all modifications, equivalents, and alternatives falling withinthe spirit and scope of the present invention as defined by the appendedclaims. The detailed descriptions below are designed to make suchembodiments obvious to a person of ordinary skill in the art.

Media for managing an interactive streaming image system are disclosed.More particularly, hardware and/or software for generating, encoding,and transmitting image frames to an interactive client are disclosed.One embodiment provides a method for streaming images from a server to aclient. Embodiments may include receiving from the client via a networkclient information and generating a new image frame based on thereceived client information. Embodiments may also include comparing thenew image frame and a previous image frame and setting a new compressionlevel based on the comparison between the new image frame and theprevious image frame. Embodiments may also include encoding the newimage frame based on the new compression level and transmitting theencoded new image frame and an indication of the new compression levelto the client via the network.

The disclosed embodiments provide a methodology and system for managingan interactive streaming image system. In the disclosed embodiments, aserver may generate a new image frame for each frame of a streamingimage based on client information received from a client. By comparingthe new image frame with a previous image frame, the disclosed systemmay advantageously determine whether content has changed between frames.Based on the difference between image frames, the disclosed system mayadjust the compression level for the encoded image frame to betransmitted to the client. If the content is changing between frames,the disclosed system may increase the compression level and reduce thebandwidth required to transmit the image frame. Similarly, if thecontent is not changing between frames, the disclosed system maydecrease the compression level and improve the quality of the ultimateimage. A user watching rapidly changing content is likely to need lesserquality of image than a user watching a static image. The disclosedsystem may also advantageously use a smoothing heuristic to smoothtransitions between compression levels and to reduce the impact onviewing quality. Accordingly, the disclosed system may provide amethodology for reducing the bandwidth required for a streaming imagesystem based on the user interaction with the system while maintainingacceptable image quality for the user.

While specific embodiments will be described below with reference toparticular configurations of hardware and/or software, those of skill inthe art will realize that embodiments of the present invention mayadvantageously be implemented with other substantially equivalenthardware and/or software systems.

Turning now to the drawings, FIG. 1 depicts an environment for a systemfor streaming images from a server to a plurality of clients accordingto one embodiment. In the depicted embodiment, the interactive imagestreaming system 100 includes a server 102 and one or more clients 106connected via a network 104. The clients 106 may transmit clientinformation to the server 102 via network 104 and the server 102 maythen generate a new image frame based on the client information. Afterthe server 102 generates the new image frame, it may then encode theimage frame at a defined compression level and transmit the encodedimage frame and an indication of the compression level used to encodethe image frame to the client 106. The client 106 may then decode theimage frame based on the compression level and display the image to auser. Using the interactive image streaming system 100, the client 106and server 102 may thus work together to generate each image frame of astreaming image stream based on client information from each cycle. Theinteractive image streaming system 100 may advantageously choose anappropriate level of compression (as will be described in more detailsubsequently) based on the client information, the difference betweensuccessive images, and other information, which may result in moreefficient use of bandwidth and processing in an interactive imagestreaming system 100.

The server 102, the one or more clients 106, and any or all of theircomponents may execute on a general or special purpose computer systemsuch as one or more of a personal computer, workstation, server,mainframe computer, notebook or laptop computer, tablet PC, desktopcomputer, portable computer system, PDA, set-top box, mobile phone,wireless device, or the like. The computer system may, in oneembodiment, include a central processing unit (CPU) and associatedvolatile and non-volatile memory, including random access memory (RAM)and basic input/output system read only memory (BIOS ROM), a systemmonitor, a keyboard, one or more flexible diskette drives, a CD-ROMdrive, a fixed disk storage drive (also known as a “hard drive” or “harddisk drive”), a pointing device such as a mouse, and an optional networkinterface adapter, all electrically connected using a motherboard orsystem planar to electrically connect these components together. Theserver 102 in one embodiment may be an International Business MachineCorporation (IBM®) eServer or similar server having one or moreprocessors, or threads of processors, executing software and/or one ormore state machines coupled with data storage devices such as RAM, readonly memory (ROM), flash memory, compact disk drives, hard drives, andthe like. The client 106 in one embodiment may be a wireless devicehaving a processor coupled with data storage devices and user input andoutput devices, such as a keypad and display screen.

Network 104 may be any type or combination of data communicationschannels, such as the Internet, an intranet, a LAN, a WAN, an Ethernetnetwork, wireless network, etc. The Internet or other public network maybe particularly useful as network 104 when a centrally located server102 is transmitting streaming image content to a plurality ofdistributed clients 106 as communications between these will befacilitated. Some or all of the clients 106 may be communicating withthe Internet network 104 (and the server 102) via a wireless network104. Those skilled in the art will recognize, however, that theinvention described herein may be implemented utilizing any type of datacommunications channel.

The server 102 may include components such as a communications module110, a content change detector 112, a content generator 114, a contentencoder 116, and a smoothing module 118. The communications module 110may facilitate the server 102 in transmitting information to a client106 via network 104 as well as receiving information from client 106 vianetwork 104. The communications module 110 may use any type of protocol,such as client-server protocols, in its communications with clients 106.In one embodiment, the server 102 may receive client information fromclients 106 using communications module 110 and may transmit encodedimage frames and/or compression information to clients 106 usingcommunications module 110. Client information may include informationidentifying the client 106 or its user (or the user's preferences) aswell as information relating to the image that should be streamed to theclient 106, such as the user's current location or orientation. In oneexample, for an image streaming application that displays to a user a3-dimensional (3-D) image based on their current position, clientinformation may include an indication of the user's position, such ascoordinates. For another application that displays to a user a virtualrendering of what they should see, client information may also includedirectional information such as a compass direction that provides anindication of the direction the user is looking. Those skilled in theart will recognize that any type of information may be included asclient information.

The content generator 114 may generate a new image frame based on theclient information received by the communications module 110. Thecontent generator 114, which may be a multi-media or streaming imageapplication, may use any type of methodology to determine the contentsof a new image frame. The content generator 114 may, for example,generate a new image frame based on the current location or direction ofthe client 106 or its user, based on the received or calculated speed ofthe user, based on the occurrence of an event, based on the currenttime, based on current weather or lighting conditions, based on thelocation of other clients 106 or users, or any other factors. In oneexemplary embodiment, content generator 114 generates a new image frameto create a 3-D representation of the current location of the client106. In another exemplary embodiment, content generator 114 may generatea new image frame that depicts a virtual view of what a user with client106 would see based on their current location and direction. The contentgenerator 114 in another embodiment may determine the velocity anddirection of the client 106 based on repeated receipt of clientinformation and may then use the determined velocity and direction togenerate an appropriate new image frame.

The content change detector 112 may analyze the new image framegenerated by the content generator 114 and compare it with the previousimage frame to determine if they differ. The content change detector 112may use type or combination of methodologies to determine if the contentbetween a new image frame and a previous frame changed. The methodologyused by the content change detector 112 may be selected by anadministrator or user, may be based on current network 104 conditions,or other factors. In one embodiment, the content change detector 112 mayuse a comparison of the compression sizes of each image frame todetermine whether a change has occurred. A non-changing compressed imageframe size in an interactive system likely indicates that the client 106is requesting the same image repeatedly and the successive image framesare the same. In another embodiment, the content change detector 112 mayutilize vector or statistic processing of bit maps of two image framesby using Boolean analysis to determine if there is a difference betweenvectors. In a further embodiment, the content change detector 112 mayutilize an indexed version of the vector of statistic processingalgorithm when the image has more regularity and speed is more critical.In an alternative embodiment, the content change detector 112 may usescene tracking or other algorithms to attempt to predict the level atwhich the user of the client 106 is interacting with her environment,using the prediction to help determine whether a new image frame is thesame as a previous image frame. In another alternative embodiment, thecontent change detector 112 may use the client information to determineif a change in image has occurred, as if there is no change in theclient's position, for example, the image may be unlikely also tochange. In another alternative embodiment, the content change detector112 may use one of the content change detection methods to determine themagnitude or degree of the change between image frames instead ofwhether a change has occurred. This may be useful when the magnitude ordegree of change will have an impact on the chosen compression level.

The content encoder 116 and smoothing module 118 may serve to, incombination or singly, determine the appropriate level of compressionfor the image frame to be transmitted to and to encode the image frameat the selected level of compression. In one embodiment, if there is nocontent change between successive image frames (as determined by thecontent change detector 112), the content encoder 116 may desire toimprove the quality of the image frame to be transmitted (and thus lowerthe compression level). In an interactive image streaming system, astatic image (not changing between successive frames) indicates that theimage from the client's point of view is stationary and image quality isthus raised in importance. In contrast, if successive images differ fromeach other, the client 106 point of view has motion and a lower qualityof image may be utilized (with higher compression levels). When a useris viewing an image depicting motion, details in the image may be lessimportant as details become blurred and the eye accounts for the loss indetail. When a user is viewing an image that is still, image details maybe more important as the user will be more likely to see any flaws orlack of details, compression artifacts, and the like.

The disclosed system advantageously adapts the compression level basedon the motion depicted in the image stream (as represented by thedifference, or lack thereof, between successive images) based on theperceived motion of the user and/or client 106. When successive imagesvary between each frame (implying motion), the content encoder 116 mayincrease the compression level and reduce the bandwidth requirementswithout detracting from the user's viewing experience. When successiveimages are the same (implying a stationary client 106), the contentencoder 116 may decrease the compression level and increase the qualityof the image. While such action may increase the bandwidth requirements,streaming image quality for the user may be preserved. In oneembodiment, the content encoder 116 may not need to transmit successiveidentical images and instead may transmit only an indication to the usethe previous image, saving bandwidth in the stationary user situation.In an alternative embodiment, the content encoder 116 and smoothingmodule 118 may base the selected compression level also on the magnitudeor degree of change between frames so that slight changes to the framedo not cause large jumps in the level of compression.

The content encoder 116 may optionally use the smoothing algorithms ofthe smoothing module 118 to smooth the transition between differentlevels of compression to improve the user experience. The smoothingmodule 118 may use an initial compression level, a target compressionlevel, and a number of frames the system is willing to wait to meet thetarget compression level as inputs. In one embodiment, the smoothingmodule 118 may vary the compression level via the lossy quantizationstep of compression standards such as Motion-JPEG or MPEG, as describedin more detail in relation to FIG. 5. The compression algorithmdescribed in relation to FIG. 5 may utilize multiplier lookup tables 120for different levels of compression as required. Those skilled in theart will recognize that the smoothing module 118 may use any type ofsmoothing mechanism.

The disclosed interactive image streaming system 100 may provide aneffective and efficient mechanism for streaming interactive image datafrom a server 102 to one or more clients 106. The server 102 of thedisclosed embodiments may compare the content of successive image framesin order to ascertain if content is changing from frame to frame. If thecontent is changing, reflecting a client 106 that is moving, the server102 may increase the compression level (and thus lower image quality andbandwidth requirements) and may advantageously use the smoothing module118 to make the change in compression level less intrusive to the user.If the content is not changing, reflecting a client 106 that isstationary, the server 102 may decrease the compression level to improveimage quality as any users are more likely to notice degradation inquality resulting from compression. By tying the compression level ofthe streaming image stream to the status of the client 106 and/or user,the interactive image streaming system 100 may reduce the bandwidthrequired for the streaming image content without significantly reducingthe quality of the images displayed to a user. By smoothing thetransitions between different compression levels, the visual quality ofstreaming images may thus be preserved while operating within networkconstraints.

FIG. 2 depicts the structure of a client of the streaming image systemof FIG. 1 according to one embodiment. In the depicted embodiment,client 106 includes a communications module 202, a decoder 204, a userdisplay device 206, a user input device 208, a location determiningdevice 210, and a directional determining device 212. Similarly to thecommunications module 110 of the server 102, the communications module202 may facilitate the client 106 in transmitting information to server102 via network 104 as well as in receiving information from server 102via network 104. The communications module 202 may use any type ofprotocol in its communications with server 102. In one embodiment, theclient 106 may transmit client information to server 102 usingcommunications module 202 and may receive encoded image frames and/or anindication of a compression level from server 102 using communicationsmodule 202.

The decoder 204 may decode the encoded image received by thecommunications module 202, such as by decompressing the encoded image.The decoder 204 may use the indication of the compression level receivedby the communications module 202 to assist it in decoding the image.Additionally, the decoder 204 may access one or more multiplier lookuptables associated with the compression level so that the decoder 204 mayproperly decode the image. After the decoder 204 processes the image,the user display device 206 may display the decoded image to the user,such as by a display screen, printed images, holograms or any otheroutput device.

As described previously, client information may include indications of auser and/or client 106's identity, preferences, location, orientation,or other information. The optional user input device 208, locationdetermining device 210, and directional determining device 212 may helpsolicit or provide client information. The user input device 208, forexample, may receive user input from any type of device, such as bykeypad, keyboard, button, stylus, mouse, joystick, virtual realitydevice, voice command, or eye movement. User input may include userpreferences such as a request for a higher or lower level ofcompression, a request for faster screen rates, and the like. User inputmay also include a user location or orientation. The locationdetermining device 210 may determine a current location for the client106 and/or user. The location determining device 210 may be any type oflocation-determining device such as a Global Positioning System (GPS)receiver or an inertial measurement unit (IMU). The directionaldetermining device 212 may determine a current orientation for theclient 106 and/or user. The directional determining device 212 may beany type of directional-determining device such as an electroniccompass, GPS receiver using triangulation, traditional compass, or IMU.The client information generated by the user input device 208, locationdetermining device 210, and/or directional determining device 212 mayallow the server 102 to customize each generated image frame based onthe current status of the client 106 and/or user.

FIG. 3 depicts an example of a flow chart for generating, encoding, andtransmitting a new image frame according to one embodiment. The server102 or any of its components, alone or in combination, may perform themethod of flow chart 300. Flow chart 300 begins with element 302,receiving client information. In one embodiment, the communicationsmodule 110 may receive client information from a client 106 via network104. After receiving the client information, the content generator 112may generate a new image frame based on the received client informationat element 304. The content generator 112 may generate the new imageframe using any type of algorithm depending on the application. Forexample, the content generator 112 may generate an image framerepresenting a view from the user's point of view if the application sorequired.

The smoothing module 118 may next determine an initial compression levelfor the generated image frame at element 306. In one embodiment, thesmoothing module 118 may simply select the most recently-usedcompression level as the initial compression level. In anotherembodiment, the smoothing module 118 may base the initial compressionlevel on whether the system is within a multi-frame smoothing routine.While within a multi-frame smoothing routine, the initial compressionlevel may be based on the compression level appropriate for the currentframe of the multi-frame smoothing routine. In one example, of thesmoothing module 118 started a compression routine that started at acompression level of five (5) and ended at ten (10) over six (6) frames,incrementing one compression level per frame, the initial compressionlevel for the third frame may be compression level seven (7) (5+2=7). Inone embodiment, the smoothing module 118 may utilize a multi-framesmoothing routine that extends for one to two seconds in order to reducethe impact on the user. In one example, if the image stream was beingtransmitted at 15 frames per second a multi-frame smoothing routine of15 to 30 frames to transition from one compression level to another mayprove useful. Those skilled in the art will recognize that the smoothingmodule 118 may utilize other multi-frame compression schemes.

The content change detector 112 may compare the generated new image tothe previous image at element 308 after the smoothing module 118determines the initial compression level. The content change detector112 may use any methodology to compare the two images, as describedpreviously. If the content change detector 112 determines at decisionblock 310 that the content has changed between the generated new imageand the previous image frame, the method of flow chart 300 continues toelement 314. At element 314, the smoothing module 118 may perform asmoothing heuristic on the new image to decrease its quality andincrease the level of compression. The smoothing module 118 increasesthe level of compression as the content change between images indicatesthat the user's perspective is likely moving and that the user is thuslikely to tolerate lower image quality. If the content change detector112 determines at decision block 310 that the content has not changedbetween the generated new image and the previous image frame, the methodof flow chart 300 continues to element 312. At element 312, thesmoothing module 118 may perform a smoothing heuristic on the new imageto increase its quality and decrease the level of compression. Thesmoothing module 118 may decrease the level of compression as the lackof content change between images indicates that the user's perspectiveis likely static and that the user is thus likely to require higherimage quality.

The smoothing module 118 may perform its smoothing heuristic at elements312 or 314 using any methodology. In one embodiment, the smoothingmodule 118 may increment between the initial compression level and thetarget compression level (in the appropriate direction depending onwhether it is increasing or decreasing) through a series of compressionquality steps. For example, the smoothing module 118 may use five levelsof compression between the minimum and maximum levels of compression.For each level of compression, however, the multiplier lookup tables120, 220 of the server 102 and client 106, respectively, may each needto contain a lookup table for that level of compression, as will bedescribed in more detail in relation to FIG. 5. The number ofcompression levels requires a trade-off between memory usage at both theserver 102 and client 106 and the smoothness of the heuristic. A highernumber of compression levels may result in a smoother transition betweencompression levels but may require additional amounts of memory, whichmay be problematic particularly for a client 106 that may have limitedprocessing and memory resources. Three or more levels of compression aretypically desirable for smooth transitions but one skilled in the artwill recognize that lower levels are possible with potentially degradedperformance.

After the smoothing module 118 has performed its smoothing heuristic,the content encoder 116 may set the new compression level at element 316based on the results from the smoothing module 118. With the newcompression level the content encoder 116 may then encode the new imageframe based on the new compression level at element 318. As describedpreviously, the content encoder 116 may use any type of encodingalgorithm to encode the new image frame. The communications module 110may then transmit the encoded new image frame and an indication of thenew compression level to the client 106 at element 320, after which themethod of flow chart 300 terminates. The method of flow chart 300 mayalso return to element 302 to repeat the process for each frame.

FIG. 4 depicts an example of a flow chart for receiving user input andreceiving and displaying an image frame to a user according to oneembodiment. The client 106 or any of its components, alone or incombination, may perform the method of flow chart 400. Flow chart 400begins with element 402, receiving user input. In one embodiment, thecommunications module 202 may receive input from a user via user inputdevice 208, as described previously. Alternatively, the communicationsmodule 202 may receive input from the location determining device 210 orthe directional determining device 212. The user input device mayoptionally process the user input at element 404, such as by convertingthe input to another form for transmission. At element 406, thecommunications module 202 may next transmit an indication of the userinput to the server 102 via network 104.

After transmitting an indication of the user input, the method of flowchart 400 may continue to element 408, where the communications module202 may receive an encoded image frame from the server 102 via network104. At element 410, the communications module 202 may also receive anindication of the compression level for the encoded image frame from theserver 102 via network 104. In one embodiment, the communications module202 may receive the encoded image frame and the indication of thecompression level in the same transmission.

Using the indication of the compression level, the decoder 204 maydecode the encoded image frame at element 412. The decoder 204 may usethe multiplier lookup tables related to the indicated compression levelto perform the dequantization step of the decoding process, as describedin more detail in relation to FIG. 5. After the image frame is decoded,the user display device 206 may display the decoded image frame to theuser at element 414, after which the method of flow chart 400terminates. The method of flow chart 400 may also return to element 402to repeat the entire flow chart for each frame.

The disclosed method of flow chart 400 allows an interactive imagestream to be displayed on a client 106 device. The communications module202 may transmit an indication of the user's interaction to a server 102and receive back an encoded image frame based on the user's interaction.The decoder 204 may then decode the image frame and the user displaydevice 206 displays the decoded image frame to the user. The methods ofFIGS. 3 and 4 may be repeated for each frame to give the user aninteractive image streaming experience. The smoother heuristicsdescribed herein advantageously vary the compression level based on theuser's actions, allowing for an effective and efficient use of theavailable bandwidth.

FIG. 5 depicts an example of a flow chart for encoding and decoding animage frame according to one embodiment. The content encoder 116 of theserver 102 and the decoder 206 of the client 106, alone or incombination, may perform the method of flow chart 500. The method offlow chart 500 may represent a description of a typical video encodingand decoding scheme or algorithm, such as MPEG or Motion-JPEG. Themethod of flow chart 500 is not meant to be exhaustive and particularencoding schemes may have more steps, such as the motion compensatingsteps of the MPEG algorithm, or entirely different methodologies. Thoseskilled in the art will recognize that the method of FIG. 5 is only oneexample and other encoding/decoding methodologies may also be used withthe disclosed embodiments.

Flow chart 500 begins with element 502, where the content encoder 116may receive an input image frame to be encoded. The content encoder 116may next perform a discrete cosine transform (DCT) operation on theinput image frame. The DCT operation may be a substantially losslessmathematical transformation that takes a signal (the spatial informationof the input image frame) and transforms it into numeric data suitableto be compressed in the form of one or more 8×8 pixel blocks as output.Within the content encoder 116, the output of the DCT operation isquantized based on the selected compression level at element 506. Thecontent encoder 116 may perform the quantization step by using constantsfrom the appropriate lookup table as divisors on each 8×8 pixel blockoutput from the DCT operation. The appropriate lookup table may be alookup table associated with the selected compression level. There maybe lookup tables for each possible compression level in one embodiment.The method of flow chart 500 may then continue to element 508, where thecontent encoder 116 may compress the quantized DCT values output fromelement 506. At element 508, the content encoder 116 may rearrange thequantized DCT values in a one-dimension array in a zig-zag sequence andmay then use an entropy encoding mechanism that uses run length encoding(RLE) and/or Huffman encoding.

The decoder 206 of the client 106 may decode the encoded image frame bymathematically reversing and decompressing the encoded image frame. Thedecoder 206 may begin at element 510 by decompressing the receive imageframe and, at element 512, the decoder 206 may perform dequantization(also known as inverse quantization) on the received image based on theselected compression level. The decoder 206 may perform thedequantization step by using constants from the appropriate lookup tableas multiplication factors on each 8×8 pixel block after thedecompression step. The appropriate lookup table may be the lookup tableassociated with the selection compression level. The same lookup tablesmay be advantageously stored in both the server 102 and client 106,respectively. The decoder 206 may then perform an inverse DCTtransformation on the received image frame which results in an outputtedimage frame that may then be displayed or otherwise processed. Themethod of flow chart 500 may then terminate.

In general, the routines executed to implement the embodiments of theinvention, may be part of an operating system or a specific application,component, program, module, object, or sequence of instructions. Thecomputer program of the present invention typically is comprised of amultitude of instructions that will be translated by the native computerinto a machine-readable format and hence executable instructions. Also,programs are comprised of variables and data structures that eitherreside locally to the program or are found in memory or on storagedevices. In addition, various programs described hereinafter may beidentified based upon the application for which they are implemented ina specific embodiment of the invention. However, it should beappreciated that any particular program nomenclature that follows isused merely for convenience, and thus the invention should not belimited to use solely in any specific application identified and/orimplied by such nomenclature.

It will be apparent to those skilled in the art having the benefit ofthis disclosure that the present invention contemplates methods,systems, and media for managing an interactive streaming image system.It is understood that the form of the invention shown and described inthe detailed description and the drawings are to be taken merely asexamples. It is intended that the following claims be interpretedbroadly to embrace all the variations of the example embodimentsdisclosed.

1. A method for streaming images from a server to a plurality of clientsof an interactive streaming image system, the method comprising:receiving by the server, from the plurality of clients via a network,client information for each of the plurality of clients, the clientinformation comprising both client location information and clientdirectional information, repectively provided by a location determiningdevice and a directional determining device, for each of the pluralityof clients of the interactive streaming imagine system; generating bythe server a new image frame for each of the plurality of clients basedon the received client information; comparing by the server the newimage frame and an immediate previous image frame for each of theplurality of clients to determine whether content changed between thenew image frame and the immediate previous image frame; setting by theserver a new compression level for each of the clients based on thecomparison between the new image frame and the immediate previous imageframe for each of the clients; wherein setting the new compression levelcomprises, in response to determining a content change between the newimage frame and the immediate previous frame for a particular client,performing a smoothing heuristic on the new image frame to decreasequality and setting the new compression level based on the smoothingheuristic; and wherein further setting the new compression levelcomprises, in response to determining no content change between the newimage frame and the immediate previous frame for a particular client,performing a smoothing heuristic on the new image frame to increasequality and setting the new compression level based on the smoothingheuristic; encoding by the server the new image frame based on the newcompression level for each client, wherein encoding by the server thenew image frame based on the new compression level comprises accessing alookup table associated with the new compression level; and transmittingby the server the encoded new image frame and an indication of the newcompression level to each of the plurality of clients via the network.